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ABSTRACT:  The  representation  of  the  undersea  environment  has  often  been  ignored,  or  at  best  static,  or  pre¬ 
calculated  in  distributed  simulation.  This  paper  details  the  efforts  of  a  multidisciplinary  team  who  have  implemented  a 
dynamic  ocean  model  and  sensor  response  in  the  Joint  Semi-Automated  Forces  (JSAF)  architecture.  A  variant  of  the 
Princeton  Ocean  Model  was  run  off  the  North  Carolina  coast  to  provide  the  dynamic  environment.  The  Shallow  Water 
Acoustic  Toolset  (PC-SWAT)  that  modeled  the  AQS-14  sonar  solved  the  sonar  equation.  A  CORBA  interface  to  JSAF 
was  developed  to  replace  the  pre-calculated  look-up  tables  with  real-time  sensor  information.  This  system  was 
demonstrated  in  April  2000  at  the  Naval  Research  laboratory  and  will  be  used  in  the  Naval  War  College's  Fleet  Battle 
Experiment-Hotel  in  August  2000. 


Background 

Semi-Automated  Forces  (SAF)  heritage  with  Army  tank 
training  systems  has  led  to  a  long  evolution  of 
improvements  to  the  environmental  models  used  by  land 
platforms.  Soil  trafficability,  urban  areas,  man-made  and 
natural  objects  can  all  be  represented  in  state  of  the  art 
SAF  systems.  One  of  the  latest  improvements  is  dynamic 
terrain  that  allows  for  deformations  to  the  terrain  skin  due 
to  run-time  simulate  events..  The  percentage  of  terrain 
that  changes  during  a  simulation  is  likely  a  very  small 
percentage  of  the  entire  terrain  skin. 

Aviation  has  been  played  in  SAF  for  nearly  as  long  as  the 
land  systems.  The  atmosphere  has  usually  been 
represented  by  a  homogeneous  clear  sky  that  allows  for 


optimal  propagation  of  sensors.  The  technology  to  bring 
the  atmospheric  environment  into  the  SAF  architecture 
was  developed  in  the  Synthetic  Theater  of  War  (STOW) 
Advanced  Concept  Technology  Demonstration  (ACTD). 
The  Total  Atmospheric  and  Oceanographic  Server 
(TAOS)  was  developed  as  a  means  to  serve  the  dynamic 
environment  to  the  distributed  SAF  stations  and  was  used 
to  provide  dynamic  atmospheric  conditions  based  on  pre¬ 
computed,  time-stamped  data  sets.  The  grid  structure 
used  to  deliver  the  atmosphere  provided  variably  spaced 
vertical  layers;  however,  the  lateral  dimensions  in  all  the 
layers  were  homogeneous,  rectilinear  boxes. 

SAF  development  has  often  sidestepped  dynamic  acoustic 
interactions  for  maritime  systems.  Unlike  Army,  Navy 
came  late  to  the  SAF  community;  thus,  demands  for  a 
complete  maritime  environment  were  not  made  or  met. 
Further,  Navy  trains  in  classified  mode,  making 
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development  and  testing  more  difficult.  Lastly,  the 
undersea  environment,  like  the  atmosphere,  is  highly 
dynamic,  particularly  in  coastal  regions,  where  uniform, 
rectilinear  grids  are  not  adequate  for  representing 
tactically  significant  parameters.  Many  of  these  reasons 
for  not  implementing  a  water  column  model  for  acoustic 
sensors  in  SAF  are  being  eliminated  through  the  support 
of  the  Naval  Research  Laboratory  (NRL)  and  the  Office 
of  Naval  Research  (ONR).  The  Ocean,  Atmosphere, 
and  Space  Department  has  taken  the  lead  in  funding 
research  efforts  to  answer  the  question  of  how  much 
environment  is  enough. 

The  NRL,  code  5580,  Advanced  Information  Technology 
Branch  has  led  a  team  of  ocean  modelers  (HydroQual), 
acousticians  (Scientific  Solutions,  Inc.),  SAF  developers 
(Lockheed  Martin  Information  Systems),  and  systems 
engineers  (VisiTech,  Ltd.)  in  researching  how  much 
environmental  information  is  needed  to  model  acoustic 
sensors  in  the  littoral  water  column.  The  methodology 
they  developed  is  directly  applicable  to  environmental 
domains  other  than  ocean.  The  fundamental  process 
begins  with  using  well  validated  models  to  develop  a 
finely  resolved  environment.  That  environment  is  tested 
for  decorrelation  times  and  lengths.  Models  that  represent 
the  physical  effects  the  control  system  behavior  are  then 
run  through  this  synthetic  natural  environment.  These 
results  are  also  tested  for  decorrelation  time  and  lengths. 
This  second  set  of  decorrelations  provides  the  tactically 
relevant  temporal  and  spatial  scales  that  must  be 
represented  in  the  simulatoin. 

This  team  analyzed  the  temporal  and  spatial  decorrelation 
times  in  the  New  York  Bight  and  presented  this  work  at 
the  Fall  Simulation  Interoperability  Workshop  (SIW). 
The  next  steps  in  the  program  were  to  construct  an  ocean 
model  for  the  Onslow  Bay  area  off  Camp  LeJeune,  NC, 
extended  the  JSAF  application  to  work  with  an  acoustic 
sensor  service,  and  integrated  an  existing  shallow  water 
acoustic  model  with  JSAF.  The  remainder  of  the  paper 
presents  how  these  steps  were  taken  and  reports  results 
from  our  work  thus  far. 


System  Components 


Figure  1.1.  The  Curvilinear  Grid  of  Onslow  Bay  off 
Camp  Lejeune,  NC. 

Modeling  Onslow  Bay 

Onslow  Bay  bathymetry  is  represented  in  the  Camp 
Lejeune  database  generated  by  the  Joint  Countermine 
Operational  Simulation  (JCOS)  ACTD.  This  Compact 
Terrain  Database  (CTDB)  served  as  the  starting  point  for 
our  Ocean  Modeling  at  HydroQual,  Inc. 

The  Camp  Lejeune  database  did  not  include  bottom  type 
attribution  that  describes  the  sea  floor.  Examples  of 
attributions  are  Fine  Sand,  Coarse  Sand,  Sandy  Gravel. 
Gravelly  Sand,  Mud,  etc.  Bottom  attribution  is  important 
for  Mine  hunting  sonar  frequencies,  as  sonar  system 
performance  is  critically  sensitive  to  backscatter,  which 
varies  with  bottom  type.  For  example,  a  rocky  bottom  is 
more  difficult  to  hunt  than  a  sandy  one.  Any  simulation 
of  mine  or  countermine  operations  in  coastal  waters  must 
include  bottom  type.  In  operational  planning,  search 
areas  and  asset  allocations  are  often  based  primarily  on 
what  is  known  about  the  characteristics  of  the  bottom  For 
the  April  demonstration  a  homogeneous  bottom  type  was 
used.  This  limited  the  team’s  ability  to  examine  the 
PCSWAT  response  to  bottom  attribution  changes,  but 
allowed  an  early  test  of  the  other  portions  of  the  dynamic 
water  column  environment.  In  Fleet  Battle  Experiment- 
Hotel1  (FBE-H),  the  database  will  include  appropriate 
bottom  attribution  in  the  bathymetry  in  the  MCM  area  of 
operations. 

An  orthogonal  curvilinear  grid2  was  developed  for  the 
Onslow  Bay  area  (Figure  1.1).  This  type  of  grid  structure 
is  typically  used  by  hydrodynamicists  as  a  means  of 
providing  the  highest  resolution  only  where  it  is  needed. 
The  grid  has  50  cells  offshore  direction  and  120  cells 
along  shore  direction.  The  horizontal  grid  spacing  ranges 
from  1  km  inshore  to  2.5  km  offshore  locations.  The 


model  domain  covers  approximately  100  by  150  km  area. 
Vertical  resolution  is  accomplished  by  employing  equally 
spaced  1 1  sigma  levels  so  that  the  model  adequately 
resolves  the  important  physical  processes  in  the  vertical 
plane.  These  1 1  sigma  levels  represent  equal  fractions  of 
water  depth  for  each  grid  so  that  deep  water  and  shallow 
water  has  same  number  of  vertical  layers.  A  numerical 
ocean  model.  Estuarine,  Coastal,  and  Ocean  Model 
(ECOM),  was  run  to  produce  three-dimensional  time- 
varying  ocean  environment.  The  model  requires 
initialization  data  and  updated  forcing  data  to  run  long 
periods  of  time.  At  the  Open  ocean  boundary,  forcing 
data  are  extractred  from  NOAA's  Coastal  Ocean  Forecast 
System  (COFS)  archives.  NOAA's  COFS  archives 
provide  hourly  sea  surface  elevations  and  daily  horizonal 
and  vertical  temperature/salinity  information  along  the 
Onslow  Bay  model  boundaries.  Atmospheric  forcing  data 
such  as  spatially  varying  wind  speed  and  direction,  air 
temperature,  barometric  pressure,  and  relative  humidity 
are  provided  by  NOAA's  National  Environmental  Center 
for  Modeling  (NCEP)  archives.  NCEP's  meteorological 
model,  Eta,  archived  these  parameters  for  every  three 
hours.  Figure  1.2  shows  the  inputs  and  outputs  from  the 
ECOM  model. 


Figure  1.2.  The  inputs  and  outputs  of  the  ECOM 
Ocean  Model.  Yellow  boxes  indicate  data  that  were 
not  used  for  this  event. 

The  ECOM  model  was  run  for  sixty  days  (simulation 
time)  from  1  Aug  1997.  Some  of  the  ECOM  forcing  data 
and  output  data  are  available  on  the  internet3.  The  model 
results  were  archived  in  netCDF  format  to  be  accessed  by 
JSAF.  This  self-describing,  platform  independent  data 
format  is  widely  used  in  numerical  computation.  The 
ECOM  output  gave  eleven  depth-levels  for  each  point  in 
the  curvilinear  grid.  The  output  consists  of  hourly  sea 
surface  elevations  and  sets  of  three  dimensional  data 


including  horizontal  and  vertical  currents,  temperature, 
salinity,  and  turbulent  kinetic  energy.  Without 
appropriate  bottom  attribution,  the  suspended  sediment 
would  not  be  used  in  the  PCSWAT  call  and  was  therefore 
not  used  in  the  environment  file. 

JSAF  uses  wave  height,  wave  period,  and  wave  direction 
to  affect  the  kinematics  of  maritime  platforms;  however, 
the  side  scan  sonar  systems  are  towed  bodies  with  control 
systems  that  make  them  relatively  insensitive  to  these 
parameters.  For  this  reasons,  these  sea  surface  parameters 
were  not  included  in  the  environmental  data  file 

PC-SWAT 

The  acoustic  response  of  the  side  scan  sonar  was 
computed  using  the  Personal  Computer  Shallow  Water 
Acoustic  Toolset  (PCSWAT),  developed  by  the  Naval 
Surface  Warfare  Center  -  Panama  City,  Coastal  Systems 
Station  (CSS).  For  a  give  set  of  input  data,  it  delivers  the 
response  of  the  side  scan  sonar  to  mines  and  mine-like 
objects  in  terms  of  a  signal-to-noise  ratio  The  PCSWAT 
Server  is  a  multithreaded  Windows®  application  for 
interfacing  JSAF  clients  with  the  PCSWAT  application. 
Data  are  sent  to  and  received  from  the  PCSWAT  server 
by  way  of  MICO,  a  Gnu  Public  Licensed  implementation 
CORBA. 

Using  MICO,  the  server  listens  on  an  available  port, 
typically  8888.  The  client  must  know  ahead  of  time  what 
the  name/IP  address  of  the  server  is  and  what  port  the 
server  is  listening  on.  After  establishing  a  connection  to 
the  server,  the  client  has  four  functions  by  which  to 
communicate  with  the  server.  These  functions  are  as 


follows: 

void 

returnSNR ( 

in 

SonarPro j ector 

sonProj , 

in 

SonarReceiver 

sonRec , 

in 

Doppler 

dpplr , 

in 

SonarEnvironment 

snrEnv, 

in 

SVPdata 

svpdata, 

in 

Target 

tgt. 

in 

Bottom 

btm. 

out 

SNR 

result) ; 

void 

requestSNR ( 

in 

SonarPro j  ector 

sonProj , 

in 

SonarReceiver 

sonRec , 

in 

Doppler 

dpplr , 

in  SonarEnvironment  snrEnv, 
in  SVPdata  svpdata, 
in  Target  tgt, 
in  Bottom  btm, 
out  long  request_id) ; 


long  pollSNR( 

in  long  request_id) ; 

void  getSNR( 

in  long  request_id, 

out  SNR  result)  ; 


SNR  is  the  signal-to-noise  ratio,  a  key  input  to  a  detection 
model  to  determine  if  a  mine  is  detectable.  The  method 
returnSNR  allows  the  client  to  encapsulate  and  transmit 
all  the  needed  parameters  describing  the  attributes  of  the 
sonar,  the  environment,  the  sound  velocity  profile  of  the 
water,  the  bottom  type,  and  the  target's  range  and  bearing. 
The  server  queues  up  the  call  and  executes  the  various 
calls  from  clients  on  a  first  come,  first  served  basis.  The 
SNR  is  returned  as  a  result.  This  is  a  blocking  call  for  the 
client. 

CORBA  Dynamic  Invocation  Interface  (DII)  services 
support  the  ability  to  execute  this  method  as  a  deferred 
synchronous  call,  and  provides  for  polling  and  a  blocking 
call  to  return  the  results.  We  found,  however,  that  with  the 
MICO  implementation  of  these  services,  polling  never 
returned  a  positive  result,  even  when  the  server  had 
clearly  completed  the  SNR  computation.  A  non-blocking 
server  was  necessary  because  of  the  JSAF  requirement  to 
maintain  at  least  a  two  hertz  rate  for  several  behaviors  and 
the  fact  that  the  time  involved  in  calculating  a  signal  to 
noise  ratio  can  take  approximately  one  second.  Multiple 
clients  simultaneously  querying  the  server  could  result  in 
unacceptable  delays  for  the  clients. 

The  methods  requestSNR.  pollSNR,  and  getSNR  provide 
an  alternative  interface  for  non-blocking  service  calls.  The 
method  requestSNR  provides  the  server  with  all  of  the 
same  input  information  as  returnSNR  does.  After  the 
server  receives  this  information  it  is  placed  in  a  queue  and 
the  function  returns  immediately  providing  the  client  a 
handle  to  the  request. 

The  method  pollSNR  allows  the  client  to  check  on  the 
status  of  its  request.  Aboolean  value  is  returned 
immediately  that  lets  the  client  know  if  its  request  has 
been  processed. 


The  method  getSNR  is  a  blocking  call  that  returns  the 
range  and  signal  to  noise  ratio  based  on  the  parameters 
passed  by  requestSNR.  If  the  request  has  not  yet  been 
processed  it  will  wait  until  the  server  gets  to  that  request 
holding  the  client's  thread  of  execution  hostage. 
Consequently,  this  is  why  it  is  important  to  first  check  the 
status  of  the  request  using  pollSNR  first. 

The  server  creates  a  worker  thread  upon  creation  that 
continuously  monitors  the  request  queue  for  any  inputs. 
When  an  input  is  found  the  server  removes  the  request 
from  the  queue  and  places  it  into  an  input  file  for  the 
PCSWATM.EXE  program  from  Coastal  Systems  Station. 
PCSWATM.EXE  is  executed  and  that  generates  an  output 
file.  The  output  file  is  parsed  for  the  desired  range's 
signal  to  noise  ratio  and  that  information  is  placed  into  a 
result  queue.  A  Mutex  is  used  when  operations  are 
performed  on  the  queues  to  prevent  errors  from 
simultaneous  data  access. 

Since  all  the  parameters  for  a  request  are  stored 
individually  several  different  clients  simulating  different 
types  of  sonars  can  all  request  signal  to  noise  ratios  at  the 
same  time  without  reconfiguring  the  server.  MICO  can 
handle  multiple  calls  from  several  different  clients  at  the 
same  time,  and  since  a  handle  is  used  for  polling  and 
retrieval  of  data  the  responsibility  for  retrieving  a  request 
is  placed  on  the  client. 


Client  1  Client  2 


Figure  2  The  PC-SWAT  acoustic  sensor  server 

A  simplified  PCSWAT  server  has  been  tested  with  up  to 
twenty  test  clients  making  a  request  and  then  waiting  for  a 
response.  The  simplified  server  didn’t  actually  invoke  the 
PCS W ATM  software  but  instead  returned  a  default  range 
and  signal  to  noise  ratio.  This  allowed  the  server  to 


rapidly  receive  and  respond  to  multiple  clients  and  ensure 
that  no  deadlock  conditions  existed  between  the  two 
threads.  The  PCSWAT  server  performed  well  with  this 
free  implementation  of  MICO  proving  it  to  be  a  viable 
solution  for  cross  platform  communication. 

JSAF 

When  JCOS  was  originally  developed,  it  used  sets  of 
look-up  tables  to  determine  the  performance  of  mines  and 
countermine  systems.  Because  of  the  cost  of  computing 
large  sets  of  these  tables  for  differing  environmental 
conditions,  the  simulation  typically  used  only  one  set  of 
tables  for  a  single  execution.  Thus  there  was  no  change  in 
performance  with  different  locations  in  the  operational 
space  or  for  the  duration  of  the  operation.  To  permit  the 
simulation  to  respond  to  the  temporal  and  spatial 
variability  that  characterizes  the  littoral  regions,  it  was 
desirable  to  replace  the  tables  with  a  data  server  and  an 
effects  server.  PCSWAT  was  thus  developed  into  the 
effects  server..  If  no  PC-SWAT  model  is  available  the 
look-up  table  is  used  for  the  sonar  sensor.  Only  the  AQS- 
14  sonar  is  currently  modeled  in  the  team’s  version  PC¬ 
SWAT. 

The  client  was  integrated  into  JSAF  4.9  with  a  library 
called  libpcswat.  This  library  takes  as  parameters  both 
the  name  of  the  server  machine  and  the  port  that  it  is 
running  on.  MICO  is  initialized  and  libpcswat  exposes  a 
function  for  requesting  a  signal  to  noise  ratio.  The  SNR 
request  function  is  passed  a  callback  that  is  invoked  upon 
discovery  of  the  completed  request.  Libpcswat  is 
periodically  ticked  and  during  this  time  a  call  to  the 
PCSWAT  server  is  made  to  check  on  the  status  of  any 
requests  made.  If  a  request  is  ready,  getSNR  is  called  to 
retrieve  the  data  and  that  is  then  passed  on  to  the  callback 
function.  Checks  are  also  made  before  the  callback  is 
invoked  to  ensure  the  vehicle  that  made  the  request  is  still 
alive. 

TAOS 

The  role  of  data  server  was  filled  by  TAOS.  TAOS  1.24 
currently  inputs  data  in  two  primary  formats  both 
developed  by  the  World  Meteorological  Organization5: 
Gridded  Binary  data  (GRIB)  and  Binary  Universal  Form 
for  the  Representation  of  meteorological  data  (BUFR).  A 
large  number  of  historical  environmental  datasets  is 
available  in  these  formats  through  the  services  of  the 
Master  Environmental  Library  (Mel),  a  data  broker 
developed  under  sponsorship  of  the  Defense  Modeling 
and  Simulation  Office  (DMSO6. 

The  output  of  the  HydroQual  ECOM  model  could  have 
been  translated  into  BUFR  format  (essentially  a  list  of 
locations  with  the  associated  parameter  values  at  those 
locations)  to  be  ingested  into  a  TAOS  environmental 


database.  While  BUFR  is  an  easy  way  to  read  data,  there 
are  problems  associated  in  searching  the  data  efficiently. 
Gridded  data  is  readily  searched;  however,  GRIB  format 
could  assumes  a  regular,  rectilinear  grid  and  the 
hydrodynamic  data  is  produced  on  an  orthologonal 
curvilinear  grid..  Thus,  each  readily  available  format 
presented  problems. 

We  chose,  instead,  to  extend  TAOS  so  that  it  could  read 
the  non-uniform  grid,  but  search  the  data  efficiently., 
TAOS  reads  the  grid  as  though  it  were  in  the  usual, 
uniform  format.  At  the  same  time  the  data  required  to 
transform  the  locations  stored  in  TAOS  to  the  appropriate 
locations  on  the  orthogonal  curvilinear  grid  was  stored  in 
a  file  that  was  pre-distributed  as  static  data  to  each  SAF 
station.  TAOS  would  receive  and  process  the  information 
as  though  it  were  in  the  known  GRIB  format.  SAF 
stations  would  received  the  data  from  TAOS,  but  ignore 
the  location,  transforming  it  to  the  correct  position  using 
the  information  in  the  pre-distributed  file. 

This  technique  was  chosen  for  a  few  reasons.  Most 
importantly,  the  orthogonal  curvilinear  grid  developed  by 
HydroQual  is  customized  for  the  particular  region  of 
interest.  Secondly,  the  environmental  information  is  best 
represented  on  a  grid,  as  opposed  to  a  series  of 
measurements  made  at  arbitrary  locations.  On  a  grid, 
algorithms  can  be  used,  based  on  parameter  values  at 
neighboring  grid  cells,  to  interpolate  over  the  various 
environmental  parameters.  Another  a  gridded 
representation  is  that  many  of  the  algorithms  and  their 
underlying  data  structures  had  already  been  developed  for 
grids  during  unit  testing  of  the  SAF  stations. 

The  main  advantage  of  this  approach  over  pre-distributing 
the  entire  set  of  ECOM  outputs  as  a  flat  file  is  that  the 
ECOM  model  can  be  run  “in-stride”  with  the  simulation. 
When  run  in-stride,  the  ECOM  model  is  driven  by  real¬ 
time  fleet  weather  forecasts.  In  this  way  the  outputs  of  the 
ECOM  model  can  be  simultaneously  distributed  to  the 
SAF  stations  as  a  “now-cast”  representation  of  the  current 
water  column  environment. 

These  extensions  to  TAOS  have  been  completed  and  are 
being  tested  for  use  in  FBE-H  in  August  2000. 

Results 

The  system  components  were  brought  together  in  April, 
2000,  at  the  Naval  Research  Laboratory  for  a  system 
integration  test.  A  number  of  problems  were  discovered 
with  the  system  components,  but  the  overall  process  and 
concept  proved  sound. 

The  output  of  the  ECOM  model  was  imported  to  the  AVS 
visualization  package  at  the  NRL  VR-Laboratory7.  The 
netCDF  file  was  transformed  into  the  appropriate  AVS 
format  and  display  in  the  VR-Lab’s  GROTTO  using  3D 


computer  graphics.  A  selection  of  these  images  may  be 
found  on  the  project’s  website.8 

The  PC-SWAT  model  exhibited  some  instability, 
returning  nonsense  values  that  were  traced  back  to  a  bug 
in  the  SWAT  architecture.  This  has  been  corrected  for 
the  FBE-H  use. 

The  integration  test  was  hampered  the  fact  that  the  terrain 
database  on  which  the  SAF  entites  move  did  not  have 
ocean  bottom  type  attributes.  There  were  not  sufficient 
resources  to  develop  and  deploy  bottom  attribution 
features  for  the  Camp  Jejune  database  for  this  integration. 
A  homogenous  bottom  type  was  assumed  for  the 
experiment.  A  bottom  attribution  feature  is  scheduled  to 
be  created  for  the  area  off  Panama  City,  FL,  in  time  for 
the  August  exercises.. 

A  set  of  comparisons  were  performed  between  versions  of 
the  software  that  used  the  original  data  tables  and  the 
newly  developed  data  and  effects  servers.  Performance  of 
the  AQS-14  responded  appropriately  to  the  dynamic 
environment  introduced  by  the  servers.  Further  tests  and 
comparison  with  live  data  will  be  needed  to  validate  the 
model's  performance. 

The  use  of  servers  is  particularly  valuable  when  trying  to 
maintain  consistency  of  system  performance  across  a 
group  of  federated  sensor  models.  Because  TAOS  can 
handle  atmospheric  and  water  column  data,  the 
coordinated  environmental  conditions  can  be  served 
across  the  federation.  By  providing  acoustic  servers, 
multiple  sensors  can  interpret  the  served  data  in  a 
consistent  manner  by  polling  the  same  server  as 
demonstrated.  The  TAOS  server  provides  a  means  to 
distribute  data  during  an  exercise  once  it  is  properly 
configured.  The  PC-SWAT  application  provides  an 
appropriate  solution  for  serving  sensor  performance  to 
multiple  sensors  in  the  scenarios  tested  to  this  point. 
Separating  the  physics  of  the  environment  from  the  sensor 
physics  is  helping  us  add  additional  sensors  rapidly. 
Because  PCSWAT  provides  the  difficult  acoustic 
characterization,  the  sensor  model  needs  only  the 
parameters  required  to  poll  PCSWAT. 

Epilogue 

A  similar  process  will  be  used  in  the  Navy  Warfare 
Development  Command's  (NWDC)  Fleet  Battle 
Experiment-Hotel  (FBE-H)  in  August.  Here,  TAOS 
servers  will  distribute  the  environment  to  the  JSAF 
applications  that  can  use  the  environmental  information 
generated  by  the  ONR  work.  FBE-H  will  take  place  in 
the  Gulf  of  Mexico,  not  Camp  LeJeune,  requiring  a  new 
terrain  database  to  be  generated  with  appropriate 
bathymetry  and  bottom  attribution  for  the  PC-SWAT 
served  sonar  models. 


Future  work  will  extend  the  investigation  of  “how  much 
is  enough’’  environmental  information  to  other  sensors, 
systems,  and  locations.  We  are  also  examining  how  the 
data  required  for  characterizing  the  natural  environment 
can  be  made  available  through  operational  systems  in  the 
fleet.  There  is  considerable  overlap  in  what  is  needed  for 
tactical  systems  and  for  JSAF  simulations.  If  consistency 
in  data  and  performance  specification  can  be  developed 
across  tactical  decision  systems  and  simulations,  all 
maritime  systems  will  benefit. 
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